fix: remove redundant review rules and fix strategy/criteria mismatch - #348

Discourages the sentinel-placeholder-file workaround (e.g., writing a NONE.md
file when the real result is "nothing to report") used to satisfy required
file_path outputs that would otherwise be empty. The fix is to use type: string
for outputs whose list can legitimately be empty, since string outputs can
naturally carry a narrative "no items found" message.

Kept as SHOULD so genuine filesystem-artifact needs (manifests, etc.) can still
opt into a sentinel, but the common "required output can't be empty" workaround
is explicitly not a sufficient reason.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

The previous consolidation commit (1994f94) removed the duplicated rule-YAML
blocks but also removed the pointers to plugins/claude/example_reviews/*.md,
which contain the full detailed prompts that the inline YAML condenses. Those
pointers are legitimately useful — they tell an agent writing condensed inline
versions where to read for tone, intent, and checklist context.

Restored as a "Reference material" section that clearly resolves the original
inline-vs-file-based contradiction: always emit the inline form (target
projects don't have the example files), and use the example files only as
reference when deciding what the condensed inline text should say.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

The previous wording forbade any cross-file reasoning from `strategy:
individual`, which would disqualify legitimate cases like a Python code review
rule where the reviewer may need to consult other project files (imports,
references, related code, conventions) while evaluating a single changed file.

Reworded so the distinction is about whether the reviewer needs to look at the
OTHER CHANGED FILES in the same review set, not whether they need to look at
any other file at all. Individual is appropriate when focus is heavily on each
file and the reviewer is unlikely to need to see the other changed files;
matches_together is for criteria that reason about the set as a whole
(coverage, deduplication, consistency across the set).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Restructured the requirement to use SHOULD/MAY/MUST NOT explicitly, matching
the RFC 2119 style of the other requirements in this schema. The substantive
guidance is unchanged: individual is preferred when focus is on each file and
the reviewer is unlikely to need to see the other changed files (consulting
unchanged project files is explicitly allowed as MAY); matches_together is
preferred when changed files need to be looked at alongside each other; and
individual is a hard MUST NOT when any criterion is a property of the set of
changed files as a whole.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

The meta-DeepSchema governing deepschema files previously only matched
.deepwork/schemas/*/deepschema.yml and **/.deepschema.*.yml, which missed
the project's own standard schemas in src/deepwork/standard_schemas/ —
they were exempt from the rules they define for users.

Consolidated both hard-coded directory matchers into a single generic
**/deepschema.yml pattern that:
- Covers .deepwork/schemas/*/deepschema.yml (user-created named schemas)
- Covers src/deepwork/standard_schemas/*/deepschema.yml (built-in schemas)
- Covers any other location a user might put a deepschema.yml
- Self-matches the meta-schema itself, which is fine — it conforms to
  its own requirements

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>